上篇回顧
Story Telling - 簡易有效的討論
講到會議很煩很冗長沒重點還要開好幾次, 是因為一開始大家都不熟問題域, 甚至連對問題的認知都有顯著的落差
講到說故事可以讓聽者快速了解流程
講到敏捷宣言裡鼓勵互動與協作
Slide - Slide - Storytelling & Domain Stroytelling
上一篇講到敏捷開發宣言
這裡看一下Waterfall, TDD, Agile, 各自當面臨需求變更或錯誤所需要的修復成本
Examining the Agile Cost of Change Curve
在開發前, 先寫Test, 來設計與開發軟體
Reduce the feedback cycle
Agile這裡有兩種顏色, Green與Red
Red是成本相對高的作法或是文化習慣
Green則是相對低的成本
透過Model Storming(DDD的Domain storytelling, event storming or other medeling methods...),
可以減少設計或是需求梳理理解上的錯誤
透過跟跟Stackholder的協作互動, 可以減少設計或是需求梳理理解上的錯誤
其實後兩個都是在不同階段, 提早發現問題, 及早Feedback
浪費往往就是在後期才發現, 如果能盡量消弭浪費, 則能相對於以前
面對變化與錯誤時是敏捷的
But!
如果公司也沒覺得自己的Waterfall有什麼浪費的話, 也硬要改變的必要就是了
DDD的作者Eric Evan提出對於Domain的定義是
A sphere of knowledge, influence, or activity.
The subject area to which the user applies a program is the domain of the software
其中一個字sphere在OX Dictionary這樣描述的
跟Eric Evan描述的維度幾乎一樣吧XD 且同義字就是Domain
knowledge, influence, or activity
用戶圍繞在這三個主題的範疇上, 怎應用你的軟體來滿足用戶
用戶為了執行某些行為, 需要這軟體的支持
為了滿足用戶需求, 需要這軟體的支持
不搭配文字描述, 我是覺得不難看得懂, 因為這應該要我用講的搭配畫面播放XD
差別就只是先請規劃者來說個故事給開發者們聽,
當下開發者們快速的畫出這樣的業務流程
同時請規劃者也閱讀並協作修正
是這裡提倡的提早把認知跟規劃者一起協作交互溝通,
讓彼此對業務流程和問題的認知拉其的一種方法跟介入的時機點
Designer針對它所需要理解的Domain範疇可能只是一部份,
他們可以快速假設出Prototype來驗證
Q: 開發人員所需要的Domain就剛好跟Designer認知的範疇一模一樣嘛?
Q: 但開發軟體呢? 如何早點的把假設的部份給具現化來討論並驗證?
快速的給出一些Telling Storeis 與 Visualize Business Flow的好處
我懶得細細描述, 這些是出自Domain Storytelling這本書的第一小節
一種協作建模的工具
目的讓來自不同背景的與會人員, 能透過可視化的故事跟說故事的方式學習彼此的領域範疇
進到書本的第二章了, 主要講這畫布上的內容與文法
主要就
蠻多元素跟UML的Sequence Diagram類似
其實文法不多, 學習門檻非常的低
常常我們做產品都會用UserStory來描述問題與需求
這裡只是快速講怎轉換語法,
但怎從Domain storytelling慢慢的拆解映射到User story mapping
就實戰工作坊比較合適講解了
大致上到這裡Domain Storytelling故事就講完了
但軟體設計要怎進行?
我想才是大家的疑惑!
流程大概是, 從故事的流程中, 針對上面的角色,流程方向, 事物用途, 來設計出適當的邊界
然後每個邊界在Zoom In繼續分析討論, 但這時也許就能分工出去給各組去討論了
嘗試在這邊界的場景內,找出sub-domain跟aggregate
再來就能各小組來玩User Story Mapping
找出有價值或是優先權高的story跟拆分出task
再來各組搭配Example mapping
根據規格Rule(規格書通常會給), 假設出情境並給出期望的答案
這裡的展開內容, 可以做整合測試, UnitTest
甚至如果是用Gherkin語法, 還能轉成BDD所需要的測試案例
OOAD 拆成Analysis 跟Design
OOA, 來辨識What to do?
OOD, 辨識出要做什麼後, How to do?
流程也是非常雷同的, Divide & Conquer 然後持續repeat細化精化
把ProblemSpace給拆解梳理的過程就是Project(投射)到Requirement Layer(各位開發者最愛談的分層設計?)
都梳理好了分析好了, 再來投射到Design, 開始設計
最後都設計好了有規格書跟TableSchema還有UI了!? 開始寫扣, 投射到Implement
最後佈署發布
每一層其實都有其驗收條件, 不然就又要最後上線給QA背鍋去了XD
工作了快10年, 合作過不少PM/SA都說很會做軟體設計, 我是沒看到UML圖做分析設計
幾乎都看到UI Prototype + Table Schema + 數十頁的文字檔 + 人月工時都估算好了
但每次開會我問, 各層的驗收條件是什麼? 都傻住, 講不出來QQ
通常當下回應我的內容是我們這次的系統沒那麼複雜, 都是CRUD
等日後QA跑去問測試案例, 常得到的回答是我也沒辦法從畫面跟資料庫推斷出流程
(當然阿 你當初設計就沒把這些給寫下來或視覺化, 日後問時, 人都會忘XD)
我: ...真的要開發人員腦補就是了XD
QA: 暗, 只好慢慢地探索性測試
如果真有公司這樣子跑流程, 但嘴裡喊著敏捷, 我應該會覺得很困惑QQ
無形中一堆浪費, 但沒改善
可能只是想壓榨完成的時間吧
也非常多公司, 軟體/系統設計, Table Schema+API Doc都是PM/SA寫的.
開發人員都真的是按表操課, 等後面的新同事來了, 前輩&後輩也只能腦補, 因為都是對於文件的想像
右半邊的圖是OOAD的流程, 但我懶得細說了, 沒驗收條件什麼都假的QQ
都是把責任往QA跟使用者拋
有人常講以終為始, 我覺得用什麼角度解讀這句. 有人以User在想, 有人以資料流在想,
但我身為開發人員, 我更喜歡以中為始,
中間那層業務邏輯, 應該是不變得, 這的不變不是業務流程真的都不會變
而是它不應該因為資料庫變動, API協議變動, 畫面變動, 而影響到業務
相對於外部環境, 我們的領域與業務不應該受到外部環境影響而被影響
一定要有測試保護的也是這層
都只講UI+TableSchema, 也難怪這樣的公司幾乎沒在寫測試.
因為開發團隊一定問, 要測試什麼? 都在資料庫裡阿, 不就CRUD
都只講UI+TableSchema, 就一定開會時爭執這些細節XD
DST範例下載,至Modeler做Import就可, 內容是JSON格式可以進Git做版控XD
ps. Domain Storytelling是本淺顯易懂的好書, 有讀書會開團跑工作坊嘛QQ
不會畫UML跟寫測試真的是一箭殺死不知道多少自稱資深工程師的
還遇過資深工程師說把repo拆開寫很難trace
顆顆
不會很難trace阿,
可能都只想要交給DB
幫忙做完, repo純粹拿view model XD
然後就會質疑, 都model是要測試什麼? 疑
滿滿的即視感
iThome鐵人賽
看影片追技術